Subject: A new issue to consider...

From: [email-masked] (Scott Adams)
Date: Wed, 7 Jul 93 14:33:31 EDT

I joined both Cayman and the DLS SIG (or whatever it was before it
became an official SIG) recently enough that I didn't have the
opportunity to participate in the discussions before the AIW meeting
in June.  From my first reading of RFC 1434 I've been concerned about
an issue that hasn't been addressed, and I thought that I'd bring it
up now, at my earliest opportunity after the SIG meeting (I would have
brought it up there, but didn't wish to disturb the harmony of the
group...).

RFC 1434 presents a tunneling protocol built on top of a reliable
transport service, specifically TCP.  It presents what I think of as
an extremely "minimalist" mechanism for managing transport
connections, which is based on pairs of static, permanent connections
between each DLSw.  All DLSw's are expected to know of all other
DLSw's, and to establish two TCP connections to each of them (one for
each direction of flow) over which all traffic flows.

My concerns are:

1 >  The connections between DLSw's (over TCP or any other transport)
     are not managed in any explicit manner.  There is no state
     machine used to determine when they can be used, if or how they
     are recovered in case of failure, or even whether they exist.
     They have no name, and no packets are defined within the SSP
     protocol related to their existence.  They are just assumed to be
     there at all times after power-up, accessible via specified SAP's
     (TCP ports 2065 and 2067), and to work transparently.

2 >  Using TCP connections in a simplex manner is NOT an efficient use
     of resources.

3 >  Using static TCP connections between all DLSs's reduces connect
     delays, but, again, isn't an efficient use of resources when
     there isn't traffic between DLSw's.

4 >  Multiplexing ALL tunnelled link traffic on one (or two) TCP
     connections leaves all traffic extremely vulnerable to congestion
     within the internet over which the TCP connection(s) travel.
     Since IP routers commonly drop packets when interfaces become
     congested, TCP re-transmit timers often take seconds to expire,
     and ALL data transmitted after a lost segment must be
     re-transmitted by TCP, heavy traffic flows (especially bursts)
     over one or a limited number of TCP tunnels may be reduced
     dramatically for substantial periods of time before smooth
     traffic flow is re-established.

Of these, 1 and 4 are the most serious.  The lack of explicit
transport connection management seems kind of like designing a
building from the ground floor up while leaving the foundation as
white space.  This doesn't seem like a good idea for an interoperable
standard.  It also affects other issues, most notably that of
capabilities exchange (a natural place for this would be just after a
DLS Tunnel (a suggestion for what to call them) has been established
between two DLSw's - capabilities could be exchanged via SSP packets
defined for this purpose).

Congestion-caused re-transmission delays are also of concern to me.  I
asked Gene Cox of IBM about their experience with DLS on the 6611, and
whether they had observed any problems with congestion.  He indicated
that they hadn't, but that they recognize the need for more
sophisticated transport connection management.  IBM may not have seen
congestion problems for several reasons that I can think of, including
the fact that APPN uses pacing mechanisms for reducing congestion
above the link (and tunnel) level (not to mention any SSP flow-control
mechanism they might be using), and that their testing may have been
limited to small internets with low (and homogenous) traffic flow
rates (the latter is pure speculation on my part).  In any case, even
though IBM hasn't seen this problem it doesn't mean that they, or
anyone else, won't.

I'd like to suggest a couple of ways that we might consider changing
the transport management:

1 >  Define explicitly the management of transport connections between
     DLSw's.  This would include naming them (I suggest DLS Tunnels),
     defining a (simple) state machine and new SSP packets that are
     exchanged to confirm connection.

2 >  Use transport connections in a full-duplex manner (a DLSw would
     read and write data to a single transport SAP).

3 >  Support dynamic transport connections (by default, or as an option
     negotiated during capabilities exchange?).

4 >  Support multiple transport connections between DLSw's and define a
     limit to the number of LLC Connections mux'd over each (start
     with large default, then establish limit during capabilities
     exchange?).

My regards,

Scott